r? @ChrisDenton

rustbot has assigned @ChrisDenton.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

r? @Amanieu

@Amanieu the tidy issue highlights an annoying and unforeseen side-effect of this change. The vec module is now part of the prelude. In effect this means that for example this code:

fn xx(i: vec::IntoIter<i32>) {
    let _ = i.as_slice();
}

fn main() {}

that currently doesn't compile on stable would now compile. Initially I thought this would cause name collisions if users define their own vec module but so far I wasn't able to produce those, it seems to always prefer the local module. But regardless, I think we don't want to allow access to a standard library namespace without going through std, alloc or core. AFAIK there is no way to pub use only the macro and not the module namespace without modifications. I have two ideas how to tackle this, maybe we can rename vec to vec_xx internally and have separate use expressions or we have to add another crate that we can #[macro_use] inject into the prelude that only contains the vec macro. Thoughts?

See also:

• 2024 edition prelude item docs are not inlined, and cause some duplication and confusion #136102

There's an issue for this change - #53977.

@Voultapher, avoiding the vec module re-export can be done like this:

#[macro_export]
macro_rules! myvec {
    () => {};
}

pub mod myvec {
    pub struct Vec;
}

pub mod prelude {
    // Bad: re-exports both macro and type namespace
    // pub use crate::myvec;
    
    mod vec_macro_only {
        #[allow(hidden_glob_reexports)]
        mod myvec {}
        pub use crate::*;
    }
    pub use self::vec_macro_only::myvec;
}

fn main() {
    prelude::myvec!();
    let _: prelude::myvec::Vec; // error
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=5e50828c593e04ba0e98f48c9d8696b4

I've applied the suggestion by @dtolnay local tests seem promising. @Kobzol could we please do a timer run to see if this PR impacts compile-times.

env and panic (and maybe something else now?) need to be treated in the same way as vec.

@Voultapher Based on the CI failure I think that a try build would fail now.

Ok, I'll try to get the CI passing first.

@petrochenkov I went through all macros and searched the docs and env and panic seem to be the only other ones affected.

@Amanieu this program previously worked:

use std::*;

fn main() {
    panic!("panic works")
}

and now runs into:

error[E0659]: `panic` is ambiguous
   --> src/main.rs:4:5
    |
4   |     panic!("panic works")
    |     ^^^^^ ambiguous name
    |
    = note: ambiguous because of a conflict between a name from a glob import and an outer scope during import or macro resolution
note: `panic` could refer to the macro imported here
   --> src/main.rs:1:5
    |
1   | use std::*;
    |     ^^^^^^
    = help: consider adding an explicit import of `panic` to disambiguate
    = help: or use `crate::panic` to refer to this macro unambiguously
note: `panic` could also refer to the macro defined here
   --> rust/library/std/src/prelude/mod.rs:157:13
    |
157 |     pub use super::v1::*;
    |             ^^^^^^^^^

I don't see how we can resolve that without changing language import rules and or special casing the prelude import.

@petrochenkov Do you have any ideas about that?

Could you add a test making sure that the modules vec, env and panic are not in prelude?

@petrochenkov Do you have any ideas about that?

The ambiguity wouldn't happen if it was the same panic in std root and in the stdlib prelude.
However, std and core have two different panic macros.

Previously #[macro_use] extern crate std; would add the std's panic to macro_use prelude, and #[macro_use] extern crate core; would add the core's panic.
This PR always adds the core's panic.

Good that we ran crater, there seems to be a problem with the current implementation in this PR, that leads to e.g.:

[INFO] [stdout]     --> /opt/rustwide/cargo-home/registry/src/index.crates.io-1949cf8c6b5b557f/wasm-bindgen-0.2.88/src/lib.rs:41:17
[INFO] [stdout]      |
[INFO] [stdout]   41 |                   panic!("function not implemented on non-wasm32 targets")
[INFO] [stdout]      |                   ^^^^^
[INFO] [stdout] ...
[INFO] [stdout] 1006 | / externs! {
[INFO] [stdout] 1007 | |     #[link(wasm_import_module = "__wbindgen_placeholder__")]
[INFO] [stdout] 1008 | |     extern "C" {
[INFO] [stdout] 1009 | |         fn __wbindgen_object_clone_ref(idx: u32) -> u32;
[INFO] [stdout] ...    |
[INFO] [stdout] 1089 | | }
[INFO] [stdout]      | |_- in this macro invocation
[INFO] [stdout]      = note: this error: internal compiler error originates in the macro `externs` (in Nightly builds, run with -Z macro-backtrace for more info)
[INFO] [stdout] 
[INFO] [stdout] 
[INFO] [stdout] error: internal compiler error: inconsistent resolution for a macro

The majority of failures are wasm-bindgen, once that's resolved it should be down to a couple expected and acceptable regressions.

The way I've implemented it, it now resolves to std::panic and not core::panic like previously. This is probably not a problem in practice since the edge-cases where panic behaves differently are few and far between, but if someone tells me how to change it I'll do it.

I suspect that is a problem in practice here, @petrochenkov code wise in the hack how would I change the resolution to use the one it's ambiguous with, which is core::panic?

You could add a condition self.ambiguity_errors.is_empty() to the reporting of "inconsistent resolution for a macro".
Like "we are doing something incorrect, but at least it's under a deprecation lint".

⚠️ Warning ⚠️

• There are issue links (such as #123) in the commit messages of the following commits.
  Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
  • 3ff59e0

@rustbot ready

@bors try

@craterbot run mode=check-only p=1 crates=https://crater-reports.s3.amazonaws.com/pr-139493-1/retry-regressed-list.txt

☀️ Try build successful (CI)
Build commit: 09335b6 (09335b6f1bff25ec39f47f1533e126fbe1ca5f5d, parent: 11d2046fe9962720558cb15f72541f7fd170dec9)

@craterbot run mode=check-only p=1 crates=https://crater-reports.s3.amazonaws.com/pr-139493-1/retry-regressed-list.txt

👌 Experiment pr-139493-2 created and queued.
🤖 Automatically detected try build 09335b6
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

🚧 Experiment pr-139493-2 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

🎉 Experiment pr-139493-2 is completed!
📊 21 regressed and 0 fixed (6580 total)
📊 262 spurious results on the retry-regessed-list.txt, consider a retry¹ if this is a significant amount.
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

Significant regressions:

• themasch.rust-jvm.2d7418c568670d8bcc52ef7e64cc0704f9c34eb1 - dbg! is ambiguous (glob import of custom dbg vs prelude)
• dmidecode-1.0.0 - assert_eq! is ambiguous (manual glob import from prelude vs macro-expanded single import of custom partial_eq from pretty_assertions)
• gcode-0.6.1 - assert_eq! is ambiguous (manual glob import from prelude vs macro_use of custom partial_eq from pretty_assertions)
• threescalers-0.8.0 - matches! is ambiguous (manual glob import from prelude vs custom matches)
• ipcrypt-0.1.0 - cannot find macro assert_eq due to no_implicit_prelude

Insignificant regressions:

• cometbft-config-0.1.0-alpha.2 - ambiguous_panic_imports with denied lints
• deranged-0.5.4 - ambiguous_panic_imports with denied lints
• tendermint-config-0.40.4 - ambiguous_panic_imports with denied lints
• playdate-* crates - uses format_args_nl (unstable feature)
• thescribe11.Rust-SST.3765b213d621b25f400804842a040ed5916fb048 - uses format_args_nl (unstable feature)
• berkus.mre-write_to.f0dca907fc0573b643ad076f12c3f0515665cabf - uses format_args_nl (unstable feature)

Looks good enough to me, if you send fixes to the crates from the "significant" category.

Could you also write a more detailed proposal / change description for this change, so I could send it to language and library teams for formal approval?
@rustbot author

☔ The latest upstream changes (presumably #148208) made this pull request unmergeable. Please resolve the merge conflicts.